SOLR-18107: fix Log4j2Watcher, register parents#4113
Conversation
Now, explicitly traverse parent logger hierarchies when iterating through explicitly configured loggers. This ensures parent loggers are always included in Log4j2Watcher.getAllLoggers(). It seems Log4j 2.25.3 (or one > 2.21.0) changed behavior in ctx.getLoggers().
|
CC @ppkarwasz |
|
Disclaimer: I'm not 100% confident in the analysis... (done by Claude) but the code looks more robust now, in any event. |
|
Will merge tomorrow night if I hear nothing more. |
|
I'll look at it today. |
ppkarwasz
left a comment
ppkarwasz
left a comment
There was a problem hiding this comment.
Hi @dsmiley,
Looks good to me!
I don't believe we have changed anything in 2.21.0 or later to break the getAllLoggers() logic: as you remarked, the Configuration.getLoggers() does and as far as I know always did return only the explicitly defined logger configurations.
Note: last year I started logging-admin to provide a simple API that allows users to retrieve and modify the logger configuration levels in a backend-independent way. I haven't had time to work on it since, but since similar code appears in Kafka, Solr and other applications, I could prioritize its first release.
|
Thanks Piotr. I'll let this bake a few days at least on main to see if it has the intended impact on this chart: https://develocity.apache.org/scans/tests?search.rootProjectNames=solr-root&search.timeZoneId=America%2FNew_York&tests.container=org.apache.solr.handler.admin.LoggingHandlerTest&tests.sortField=FLAKY&tests.test=testLogLevelHandlerOutput# |
2 participants
Now, explicitly traverse parent logger hierarchies when iterating through explicitly configured loggers. This ensures parent loggers are always included in Log4j2Watcher.getAllLoggers(). It seems Log4j 2.25.3 (or one > 2.21.0) changed behavior in ctx.getLoggers().
https://issues.apache.org/jira/browse/SOLR-18107